Digital certificates are in wide use on the Internet and in the field of electronic commerce for authentication of all sorts of electronic transactions. In general, such digital certificates are used to certify the identity of an entity in the digital world, particularly as defined by the public key infrastructure (PKI). As digital certificates are issued and used, they often are either revoked or expire after a predetermined amount of time. In other situations, a digital certificate may be revoked or placed on hold pending some event. In order for digital certificates to be useful, it is important that those entities using digital certificates to authenticate the identity of an entity presenting the digital certificate have confidence that the digital certificate is valid. Generally, the validity of a digital certificate can be determined by reference to a Certificate Revocation List (CRL) produced by an authority that generates the certificates (usually a Certificate Authority).
FIG. 1 depicts a simple exemplary computer network 100 that utilizes a digital certificate and a Certificate Revocation List. In system 100, a user terminal 104 may request via a network (for example the Internet) 108, a digital certificate from a Certificate Authority 112. The Certificate Authority 112 generates and issues the certificate, which is returned to the user terminal 104. The user terminal 104 can then utilize the digital certificate to carry out the transaction with another entity such as remote server 116. Such transactions may include financial transactions or any other transaction in which the identity of the user terminal 104 should be reliably authenticated.
When user terminal 104 sends the digital certificate to remote server 116, the remote server 116 can inspect the digital certificate against a list of revoked certificates (the Certificate Revocation List) stored by the remote server 116. In the event remote server 116 has not obtained a recent CRL, one can be requested from the Certificate Authority 112. Certificate Authority 112 then either generates a new CRL or sends the most recently generated CRL to the remote server 116. Remote server 116 can then determine whether nor not the digital certificate sent by user terminal 104 is valid. Thus, remote server 116 can authenticate the user terminal 104 and determine whether or not to authorize particular transaction at hand.
FIG. 2 depicts a message flow diagram 200 for the transaction just described. In this message flow diagram, a certificate request 204 is sent from the user terminal 104 to the Certificate Authority 112. The Certificate Authority 112 generates a certificate at 208 and returns the certificate at 212 to the user terminal 104. The user terminal 104 can then submit a transaction using the certificate at 218 to the remote server 116. Remote server 116 can then request a new CRL at 222 of the Certificate Authority. The Certificate Authority 112 then generates or retrieves a CRL at 226 and sends the CRL to the remote server 116 at 230. Depending on the nature of the transaction, the remote server 116 may process the CRL at 232 by taking various actions including, for example, sorting, filtering or reformatting the CRL and storing information in its own database. At 234, the certificate can be authenticated against the CRL data at the remote server 116. At 238 the transaction can be either approved or rejected in accordance with the authentication at 234 and at 242 the approval or rejection can be confirmed with the user terminal 104. Those skilled in the art will recognize that many other message flows are possible with the message flow 200 if FIG. 2 being intended as exemplary of a simple use of a digital certificate and a Certificate Revocation List.
With reference to FIG. 3 the Certificate Authority 112 may generate the Certificate Revocation List in accordance with process 300. CRLs are generated at the Certificate Authority either on a periodic basis, or as a result of some event such as a certificate is revoked, or some combination thereof. The process starts at 302 after which a database of certificates is queried for certificates meeting a particular criteria of inactivity. One example is for the query to request all certificates that have been revoked. Other certificates are assumed to still be valid and active.
At 304 the certificate database at the Certificate Authority responds to the query with certificates meeting the specified criteria. Header information is then generated, for example, in accordance with X.509 and RFC 2459 standards (or other applicable CRL standards) at 312 and at 316 the certificate is formatted (for example, as an ASN.1 or other format CRL). The digital certificate is signed at 320 to assure its authenticity and is then stored at 322 within a computer residing at the Certificate Authority. The process returns at 326. Whenever a request is made for a new digital certificate, process 300 is carried out or, in some instances, the most recently generated CRL may be retrieved and forwarded to the requester.
When a CRL as generated in accordance with process 300 is sent to the remote server as in 232 of process 200, the remote server may carry out any number of processes on the CRL at 232. Such processes may include merging the CRL into existing databases, reformatting the CRL or taking other potentially computationally intensive actions. When a process such as process 300 is carried out at specified time intervals, it is possible that there has been no change in the CRL since the last CRL was sent to remote server 116. In this case, such processes at 232 are redundant and wasteful. It is therefore desirable to minimize or eliminate such processing to allow the network to carry out its functions in a responsive manner.
As digital certificates find wider use, the number of such certificates issued has increased dramatically. With this increase comes an associated increase in the number of entries in a Certificate Revocation List. Accordingly, the processing at 232 as just described can become an extremely time consuming process, depending on the nature of the processing required. This is obviously undesirable since the process of authentication using the CRL should preferably be carried out in an expedient manner.